home *** CD-ROM | disk | FTP | other *** search
-
- Network Working Group Mike Padlipsky
- Request for Comments: 949 Mitre
- Semisupersedes RFC 505 July 1985
-
- FTP UNIQUE-NAMED STORE COMMAND
-
-
- STATUS OF THIS MEMO
-
- This RFC proposes an extension to the File Transfer Protocol for the
- ARPA-Internet community, and requests discussion and suggestions for
- improvements. Distribution of this memo is unlimited.
-
- DISCUSSION
-
- There are various contexts in which it would be desirable to have an
- FTP command that had the effect of the present STOR but rather than
- requiring the sender to specify a file name instead caused the
- resultant file to have a unique name relative to the current
- directory. This would be useful for all sorts of "pool" directories;
- the directories that serve as queues for printer daemons come
- immediately to mind (so do fax and even cardpunch daemons' queues),
- although naturally the sort of printer queue that a local command has
- to manage the interface to isn't what's meant by "pool" in this
- context.
-
- If we accept the need for such an FTP extension, and that it should
- not be done with an "X" command because it needs to be relied on
- "everywhere," the interesting question then becomes how to mechanize
- it. Probably the most natural way to do it would be either to add a
- "control argument" of -UNM to the syntax of STOR, now that there are
- enough UNIXtm's around so that this good old Multics trick isn't
- alien any more, or even to declare that STOR with no argument should
- cause a directory-unique name to be generated. However, either of
- these would necessitate "reopening" the STOR command code, which is a
- distasteful sort of exercise. Since most FTP's presumably do a
- dispatch sort of thing off a list of command names to begin with,
- then, an additional command would seem to be the way to go.
-
- Naming the command calls for a bit of thought. STore Uniquely Named
- (-> STUN) is silly; UNIQue comes to close to free advertising or even
- trademark infringement (and confuses fingers if you're typing); Store
- Uniquely NaMed (-> SUNM) doesn't avoid free advertising either;
- Uniquely Named STore (-> UNST) might look like a synonym for DELEte,
- though it's not all that bad; SToRe Uniquely named (-> STRU) is
- taken; and so it goes. The best bet seems to be STOU.
-
- Of somewhat more practical import, there's also the question of
- whether the sender needs to be apprised of what the unique name
- turned out to be. Intuitively, sometimes this would be the case and
- sometimes it wouldn't. Making it optional is almost certainly too
-
-
- Padlipsky [Page 1]
-
-
-
- RFC 949 July 1985
- FTP Unique-Named Store Command
-
-
- much like work, though--even if it does have the subtle virtue of
- finally getting control arguments into FTP. Therefore, why not just
- include it in a suitable response-code's free text field (unless, of
- course, an avalanche of comments comes in urging it not be done at
- all)?
-
- Note, by the way, that the intent here is emphatically not to
- sidestep whatever access control, authentication, and accounting
- mechanisms Hosts might have in play before the user can do an old
- STOR or a new STOU, but with suitable publicized ID's and passwords
- it could be almost as good as the proposal made in RFC 505.
-
- RECOMMENDATION
-
- Add a new command, STOU, to FTP, which behaves like STOR except that
- the resultant file is to be created in the current directory under a
- name unique to that directory. The 250 Transfer Started response
- should include the name generated (unless the copy of FTP I have is
- so old that 250 isn't the right number any more).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Padlipsky [Page 2]
-
-